自动的内存管理系统实操手册——Java垃圾回收篇
一、 垃圾回收区域及划分
在介绍 Java 垃圾回收之前，我们需要了解 Java 的垃圾主要存在于哪个区域。JVM内存运行时区域划分如下图所示：
图源：深入理解Java虚拟机：JVM高级特性与最佳实践（第3版） —机械工业出版社
程序计数器：是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器，各条线程之间计数器互不影响，独立存储。
虚拟机栈：它描述的是 Java 方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame，是方法运行时的基础数据结构）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
本地方法栈：它与虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
Java堆：它是 Java 虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。
方法区：它与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
Java 内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈3个区域随着线程而生，随着线程而灭；栈中的栈帧随着方法的进入退出而进栈出栈，在类结构确定下来时就已知每个栈帧中的分配内存。而 Java 堆和方法区则不同，一个接口中的多个实现类需要的内存可能不同，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，而在java8中，方法区存放于元空间中，元空间与堆共享物理内存，因此，Java 堆和方法区是垃圾收集器管理的主要区域。
从垃圾回收的角度，由于JVM垃圾收集器基本都采用分代垃圾收集理论，所以 Java 堆还可以细分为如下几个区域（以HotSpot虚拟机默认情况为例）：
其中，Eden区、From Survivor0("From")区、To Survivor1("To")区都属于新生代，Old Memory区属于老年代。
大部分情况，对象都会首先在Eden区域分配；在一次新生代垃圾回收后，如果对象还存活，则会进入To区，并且对象的年龄还会加1(Eden 区->Survivor区后对象的初始年龄变为1)，当它的年龄增加到一定程度（超过了survivor区的一半时，取这个值和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值），就会晋升到老年代中。经过这次GC后，Eden区和From区已经被清空。这个时候，From和To会交换他们的角色，保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程。在这个过程中，有可能当次Minor GC后，Survivor 的"From"区域空间不够用，有一些还达不到进入老年代条件的实例放不下，则放不下的部分会提前进入老年代。
针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种：
1.部分收集 (Partial GC)：
新生代收集（Minor GC/Young GC）：只对新生代进行垃圾收集；
老年代收集（Major GC/Old GC）：只对老年代进行垃圾收集。需要注意的是Major GC在有的语境中也用于指代整堆收集；
混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。
2.整堆收集 (Full GC)：收集整个Java堆和方法区。
Java 堆内存常见分配策略
1.对象优先在eden区分配。大部分对象朝生夕灭。
2.大对象直接进入老年代。大对象就是需要大量连续内存空间的对象（比如：字符串、数组），容易导致内存还有不少空间就提前触发垃圾收集获取足够的连续空间来安置它们。为了避免为大对象分配内存时，由于分配担保机制带来的复制而降低效率，建议大对象直接进入空间较大的老年代。
3.长期存活的对象将进入老年代，动态对象年龄判定：在一次新生代垃圾回收后，如果对象还存活，则会进入s0或者s1，并且对象的年龄还会加1(Eden 区->Survivor区后对象的初始年龄变为1)，当它的年龄增加到一定程度（超过了survivor区的一半时，取这个值和MaxTenuringThres
hold中更小的一个值，作为新的晋升年龄阈值），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringTh
reshold来设置。
4.空间分配担保。在发生Minor GC之前，虚拟机会先检查老年代最大可用连续内存空间是否大于新生代所有对象总空间。如果这个条件成立,那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许【担保失败】：
如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小。
如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的。
如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。
二、 判断对象死亡
堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。判断一个对象是否存活有引用计数、可达性分析这两种算法，两种算法各有优缺点。Java 和Go都使用可达性分析算法，一些动态脚本语言（如:ActionScript）一般使用引用计数算法。
（一）引用计数法
引用计数法给每个对象的对象头添加一个引用计数器，每当其他地方引用一次该对象，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。
这个方法实现简单，效率高，但是主流的Java虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。即如下代码所示：除了对象objA和objB相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为0，于是引用计数算法无法通知GC回收器回收他们。
public class ReferenceCountingGc { Object instance = null; public static void main(String[] args) { ReferenceCountingGc objA = new ReferenceCountingGc(); ReferenceCountingGc objB = new ReferenceCountingGc(); objA.instance = objB; objB.instance = objA; objA = null; objB = null;
}}目前Python语言使用的是引用计数法，它采用了“标记-清除”算法，解决容器对象可能产生的循环引用问题。关于详细原理可以参考《Python垃圾回收机制详解]。
(https://blog.csdn.net/xiongchengluo1129/article/details/80462651)
（二）可达性分析算法
这个算法的基本思想就是通过一系列的称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连的话，则证明此对象是不可用的。算法优点是能准确标识所有的无用对象，包括相互循环引用的对象；缺点是算法的实现相比引用计数法复杂。比如如下图所示Root1和Root2都为“GC Roots”，白色节点为应被垃圾回收的。
关于Java查看可达性分析、内存泄露的工具，强烈推荐“Memory Analyzer Tool”，可以查看内存分布、对象间依赖、对象状态。
在Java中，可以作为“GC Roots”的对象有很多，比如：
在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
在方法区中类静态属性引用的对象，譬如Java类的应用类型静态变量。
在方法区中常量应用的对象，譬如字符串池中的引用。
在本地方法栈中JNI引用的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻异常对象（如NPE），还有系统类加载器。
所有被同步锁（synchronized）持有的对象。
反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
不可达的对象并非“非死不可”
即使在可达性分析法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”，要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize方法。当对象没有覆盖finalize方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。
判断一个运行时常量池中的常量是废弃常量
1.JDK1.7 之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时 hotspot 虚拟机对方法区的实现为永久代。
2.JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是 hotspot 中的永久代。
3.JDK1.8 hotspot 移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)。
假如在字符串常量池中存在字符串"abc"，如果当前没有任何String对象引用该字符串常量的话，就说明常量"abc"就是废弃常量，如果这时发生内存回收的话而且有必要的话，"abc"就会被系统清理出常量池了。
如何判断一个方法区的类是无用的类
类需要同时满足下面3个条件才能算是“无用的类”，虚拟机可以对无用类进行回收。
1.该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
2.加载该类的ClassLoader已经被回收。
3.该类对应的 java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
三、垃圾收集算法
当确定了哪些对象可以回收后，就要需要考虑如何对这些对象进行回收，目前垃圾回收算法主要有以下几种。
（一）标记清除算法
该算法分为“标记”和“清除”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。
适用场合：存活对象较多的情况、适用于年老代（即旧生代）。
缺点：
1.空间问题，易产生内存碎片，当为一个大对象分配空间时可能会提前触发垃圾回收（例如，对象的大小大于空闲表中的每一块儿大小但是小于其中两块儿的和）。
2.效率问题，扫描了整个空间两次（第一次：标记存活对象；第二次：清除没有标记的对象）。
（二）标记复制算法
为了解决效率问题，出现了“标记-复制”收集算法。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。使用复制算法，回收过程中就不会出现内存碎片，也提高了内存分配和释放的效率。
适用场合：存活对象较少的情况下比较高效、用于年轻代（即新生代）。
缺点：需要一块儿空的内存空间，整理阶段，由于移动了可用对象，需要去更新引用。
（三）标记整理算法
对于对象存活率较高的场景，复制算法要进行较多复制操作，使得效率会变低，这种场景更适合标记-整理算法，与标记-清理一样，标记整理算法先标记出对象的存活状态，但在清理时，是先把所有存活对象往一端移动，然后直接清掉边界以外的内存。
适用场合：对象存活率较高（即老年代）
缺点：整理阶段，由于移动了可用对象，需要去更新引用。
（四）分代收集算法
当前 Java 虚拟机的垃圾收集采用分代收集算法，一般根据对象存活周期的不同将内存分为新生代和老年代。在新生代中，每次收集都会有大量对象死去，可以选择“标记-复制”算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高，而且没有额外的空间对它进行分配担保，所以我们选择“标记-清除”或“标记-整理”算法进行垃圾收集。
四、垃圾收集器
图源：深入理解Java虚拟机：JVM高级特性与最佳实践（第3版） —机械工业出版社
垃圾 收集器 | 特点 | 算法 | 适用场景 | 优点 | 缺点 |
| Serial | 最基本、历史最悠久的单线程垃圾收集器。 | 新生代采用标记-复制算法，老年代采用标记-整理算法。 | 运行在 Client 模式下的虚拟机 | 简单、高效 | 垃圾回收时必须暂停其他所有的工作线程 |
| ParNew | Serial 收集器的多线程版本 | 新生代采用标记-复制算法，老年代采用标记-整理算法 | 运行在Server 模式下的虚拟机 | 并行，效率高 | |
| Parallel Scavenge | 使用标记-复制算法的多线程收集器，关注吞吐量 | 新生代采用标记-复制算法，老年代采用标记-整理算法. | JDK1.8 默认收集器在注重吞吐量及CPU资源的场合 | 吞吐量高 | |
| SerialOld | Serial 收集器的老年代版本 | 标记-整理算法 | 在JDK<1.5与 Parallel Scavenge收集器搭配使用作为CMS收集器的后备方案 | 简单、高效 | 垃圾回收时必须暂停其他所有的工作线程 |
| Parallel Old | Parallel Scavenge收集器的老年代 | 标记-整理算法 | 在注重吞吐量及CPU资源的场合 | 吞吐量高 | |
| CMS | 多线程的垃圾收集器（*用户线程和垃圾回收线程可以同时进行*） | 标记-清除算法 | 希望系统停顿时间最短，注重服务的响应速度的场景 | 并发收集、低停顿 | 对CPU资源敏感，无法处理浮动垃圾，产生垃圾碎片 |
| G1 | 一款面向服务器的垃圾收集器，并行并发，空间整合，可预测的停顿时间 | 标记-复制算法 | 服务端应用、针对具有大内存多处理器的机器 | 停顿时间可控、基本无空间碎片 | 可能存在空间浪费、程序运行时的额外执行负载高 |
虽然我们对各个收集器进行比较，但并非要挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。
参考文献
1.[CMS垃圾收集器]
(https://juejin.cn/post/6844903782107578382)
2.[一个专家眼中的Go与Java垃圾回收算法大对比]
(https://blog.csdn.net/u011277123/article/details/53991572)
3.《深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）》—机械工业出版社
作者简介
汪汇
腾讯后台开发工程师
腾讯后台开发工程师，负责腾讯看点相关后端业务，毕业于南京大学软件学院。
推荐阅读